Seems like the CI run at this point failed due to this error. I'll retry shortly:

#6 39.45   Could not connect to archive.ubuntu.com:80 (185.125.190.82), connection timed out Could not connect to archive.ubuntu.com:80 (185.125.190.83), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.91.83), connection timed out Could not connect to archive.ubuntu.com:80 (185.125.190.81), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.91.81), connection timed out Could not connect to archive.ubuntu.com:80 (185.125.190.36), connection timed out Could not connect to archive.ubuntu.com:80 (185.125.190.39), connection timed out Could not connect to archive.ubuntu.com:80 (91.189.91.82), connection timed out
#6 39.45   Unable to connect to archive.ubuntu.com:80:
#6 39.45 Fetched 126 kB in 39s (3208 B/s)
#6 39.45 Reading package lists...
#6 39.46 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/questing/InRelease  Unable to connect to archive.ubuntu.com:80:
#6 39.46 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/questing-updates/InRelease  Unable to connect to archive.ubuntu.com:80:
#6 39.46 W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/questing-backports/InRelease  Unable to connect to archive.ubuntu.com:80:
#6 39.46 W: Some index files failed to download. They have been ignored, or old ones used instead.

@folkertdev Seems like the clang++-19 was being passed as the value to the --cppcompiler flag, instead of clang++. That was the reason behind the No such file or directory error. Fixed it.

I ran into an issue with the process being killed (likely due to resource constraints since the clang++ processes are running in parallel). Would it be okay if I increase the CPU and memory limits within the Github workflow file?

For now I've made it sequential so that I can step over that error, but the amount of time it's taking has got me reconsidering it.

I ran into an issue with the process being killed (likely due to resource constraints since the clang++ processes are running in parallel). Would it be okay if I increase the CPU and memory limits within the Github workflow file?

I don't think that is how it works? You just get a CI machine (typically with 4 cores) for some duration. Do you know how large these files get (how many intrinsics do you generate a test for)?

We definitely want to be running these processes in parallel.

Ohh I see, I thought I could edit the resource allocation.
However, while running them in parallel I consistently run into the process being killed.

Let me experiment with keeping more number of mod_i.cpp and a worker pooling mechanism, seeing as we can't change the resource allocation.

you could also try to just cut the total number of generated tests (e.g. to 10%) to see if that helps?

By the looks of it the whole process is just way too slow, and the runners eventually time out. So, you'll have to figure out how to make it faster. I think the crux here is what I plan to do: link all the c++ and rust code into one binary that generates, in effect, a large number of rust #[test] tests, and just execute that using the given runner.

But that is probably not feasible for you in the remaining time, so by just cutting the total number of tests (maybe using some random sampling, e.g. keep every 10th test) we'll be able to merge your code without completely tanking our CI times.

Good idea @folkertdev. Let me first check whether processing smaller-sized chunks would be of any help.

@sayantn was this change related to the change we made for some x86 intrinsics? Found this in the CI tests

Illegal instruction at address = 56435cedbf49: f2 0f 2b 00 0f ae f8 f2 0f 10 04 24 66 0f 2e 
Image name: /checkout/target/x86_64-unknown-linux-gnu/release/deps/core_arch-92d6a56b530b6fbf
Offset in image: 0x6cef49
If you believe your application should attempt to execute
this illegal instruction (and others that may be present),
Then use this knob: -emit-illegal-insts 0
and this error message will be avoided.
Use -print-exception-details to get more details.

SDE ERROR: Illegal instruction at address = 56435cedbf49: f2 0f 2b 00 0f ae f8 f2 0f 10 04 24 66 0f 2e 
Image name: /checkout/target/x86_64-unknown-linux-gnu/release/deps/core_arch-92d6a56b530b6fbf
Offset in image: 0x6cef49
If you believe your application should attempt to execute
this illegal instruction (and others that may be present),
Then use this knob: -emit-illegal-insts 0
and this error message will be avoided.
Use -print-exception-details to get more details.

I don't think I have seen this before, seems to be in _mm_stream_sd. I did recently update the implementation in #1929, but the CI did pass there (and locally). It shouldn't happen if we didn't change anything, might be spurious. Worth a retry in CI

_mm_stream_sd and _mm_stream_ss seem to be in sse4a, not sse2.

Yea, and the CI failures looked like it got to sse4a and then failed (although I don't know how much we can trust output order, considering that the tests are parallelized)

SSE4a is an AMD extension, so intel-sde may not support it. Does the intrinsic tester check for feature availability before using those features?

Iirc sde supports (most) amd extensions. It even has a cpu preset named amd-future. Currently we just enable the sse4a, vp2intersect, xop and tbm in the future cpu preset of sde

our testsuite uses is_x86_feature_detected, but it's mostly useless because we completely the cpuid outputs via the -cpuid-in argument to sde (the ci/docker/x86_64-unknown-linux-gnu/cpuid.def file). SDE parses that cpuid file to see what extensions it should emulate (it can also delegate to the host cpu if the host cpu has that instruction)